home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 883 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.2 KB
  1. From: Philippe Verdy <100105.3120@compuserve.com>
  2. Message-ID: <4jc5lt$doh@arl-news-svc-2.compuserve.com>
  3. X-Original-Date: 27 Mar 1996 19:41:49 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 27 Mar 96 21:42:50 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: static members as members of a metaclass hierachy
  9. Organization: CompuServe Incorporated
  10. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  11.     iQBFAgUBMVm2Z+EDnX0m9pzZAQH3TwF9EV1fzTTF2dZWGzUrSGwWcdqAaL9im+Hl
  12.     d3rmvHfLhvxOY4X1tiM3B4p92NnaEwO2
  13.     =6lMF
  14.  
  15. Many problems in C++ are related to the need of using some
  16. static members in the definition of the class.
  17.  
  18. There are many cases where those static members have to be
  19. initialized in a proper sane order, as for any instances of
  20. the class they belong.
  21.  
  22. Shamely, the current C++ definition does not allow for a clean
  23. specification of which (and when) classes are constructed
  24. prior to using them for the construction of other classes.
  25.  
  26. Why does the C++ standard evolve to a more solid definition
  27. including metaclasses to solve this problem:
  28. So we could instantiate the class in the metaclass constructor.
  29.  
  30. One can think of creating a collection of classes as being
  31. instances of a metaclass.
  32.  
  33. How implement it ?
  34.  
  35. Simply we would define a metaclass like any other C++ class,
  36. but each class constructor (the code which instantiate static
  37. members of the class, as opposed to an instance constructor
  38. which instantiate non static members) could be more safely
  39. called and specified in the class definition itself.
  40. So we would have to manage with a structure like this :
  41.  
  42. class X : public Y, static M
  43. {
  44.  
  45. //////////// class construction part ////////////////////
  46.  
  47.   static X()
  48.     : M(parameters) // metaclass construction
  49.     , static_member1(parameters) // static members construction
  50.   {
  51.     // code to initilialize static members of X
  52.     // after calling static class M constructor
  53.   }
  54.   static virtual ~X()
  55.   {
  56.     // code to delete static members of X
  57.     // then the static class M destructor will be called
  58.   }
  59.   static class_member1;
  60.  
  61. ///////////////// instance definition part //////////////
  62.  
  63.   X() // classic instance constructor
  64.   : Y (parameter) // base class instance construction
  65.   , instance_member2(parameter)
  66.   {...}
  67.   ~X() {...} // classic instance destructor
  68.  
  69.   int instance_member2;
  70. };
  71.  
  72. Why using static (metaclass) inheritance ?
  73. Because it will ensure that this metaclass is constructed
  74. before initializing class static members.
  75. So it can provide the monitoring which allows classes to
  76. be safely constructed and deleted.
  77.  
  78. The class would not be really instances of the metaclass
  79. because each metaclass-instance (or class) is fully specified
  80. and cannot be instantiated without defining its behavior.
  81.  
  82. Then what about static members initializers ?
  83. this would only remain as a common way of initializing them
  84. when there is no static class constructor defined. In that
  85. case, the compiler generates itself the class constructor and
  86. the class destructor, by aggregating all static members
  87. initializer in a compiler-generated function.
  88.  
  89. When would the metaclass be constructed ? Like any other
  90. classes which are instanciable : by defining a static instance
  91. of the metaclass like this :
  92.  
  93. static class M; // valid if static M::M() exists
  94. static class X; // valid if static X::X() exists
  95.  
  96. We do not need then to add the whole list of static members
  97. instances because the class constructor code instantiate
  98. them itself, in the specified order.
  99.  
  100. How does the compiler control class instantiation order ?
  101. by reading the list of their static inheritances, and the
  102. compiler could manage a flag within the virtual table of
  103. each class, which is specifically devoted to this task.
  104.  
  105. There can also be some virtual class destructors I think, but
  106. I'm not sure if this would be useful or not.
  107.  
  108. What do you think of this proposal ? Would it provide
  109. additional problems ? Are there proposals which similarily
  110. go in this sense ?
  111.   
  112. ---
  113. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  114. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  115. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  116. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  117. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  118.